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(54) Methods and apparatus for providing efficient password-authenticated key exchange 


(57) A secure protocol is provided which uses a Dif- 
fie-Hellman type shared secret, but modified such that 
the two parties may authenticate each other using a 
shared password. In accordance with the invention, a 
party generates the Diffie-Hellman value <? and com- 
bines it with a function of at least the password using a 
group operation, wherein any portion of a result associ- 
ated with the function that is outside the group is rand- 
omized. The resulting value is transmitted to the other 


party. The group operation is defined for the particular 
group being used. Every group has a group operation 
and a corresponding inverse group operation. Upon re- 
ceipt of the value, the other party performs the inverse 
group operation on the received value and the function 
of at least the password, and removes the randomiza- 
tion of any portion of the result associated with the func- 
tion that is outside the group, to extract o* such that the 
other party may then generate the shared secret g*y us- 
ing Its knowledge of y. 
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Description 

Field of the Invention 

[0001] The present invention generally relates to 
techniques for providing network authentication and key 
exchange and, more particularly, to techniques for im- 
proving the computational efficiency associated with 
such network authentication and key exchange. 

Background of the Invention 

[0002] Authentication over a network is an important 
part of security for systems that allow remote clients to 
access network servers. Authentication is generally ac- 
complished by verifying one or more of the following: 

(i) something a user knows, e.g. a password; 

(ii) something a user is, i.e., biometric information, 
such as a fingerprint; and 

(Hi) something a user has, i.e., some identification 
token, such as a smart-card. 

[0003] For example, an automatic teller machine 
(ATM) verifies two of these: something a user has, the 
ATM card, and something a user knows, a personal 
identification number (PIN). ATM authentication is sig- 
nificantly easier than authentication over a data network 
because the ATM itself is considered trusted hardware, 
such that it is trusted to verify the presence of the ATM 
card and to transfer the correct information securely to 
a central transaction server. 

[0004] In addition to authentication, key exchange is 
an important part of communication across a data net- 
work. Once a client and server have been authenticated, 
a secure communication channel must be set up be- 
tween them. This is generally accomplished by the client 
and server exchanging a key, called a session key, for 
use during communication subsequent to authentica- 
tion. 

[0005] Authentication over a data network, especially 
a public data network like the Internet, is difficult be- 
cause the communication between the client and server 
is susceptible to many different types of attacks. For ex- 
ample, in an eavesdropping attack, an adversary may 
learn secret information by intercepting communication 
between the client and the server. If the adversary learns 
password information, the adversary may replay that in- 
formation to the server to impersonate the legitimate cli- 
ent in what is called a replay attack. Replay attacks are 
effective even if the password sent from the client is en- 
crypted because the adversary does not need to know 
the actual password, but instead must provide some- 
thing to the server that the server expects from the le- 
gitimate client (in this case, an encrypted password). 
Another type of attack is a spoofing attack, in which an 
adversary impersonates the server, so that the client be- 
lieves that it is communicating with the legitimate server, 


but instead is actually communicating with the adver- 
sary. In such an attack, the client may provide sensitive 
information to the adversary. 

[0006] Further, in any password-based authentication 
s protocol, there exists the possibility that passwords will 
be weak such that they are susceptible to dictionary at- 
tacks. A dictionary attack is a brute force attack on a 
password that is performed by testing a large number 
of likely passwords (e.g., all the words in an English dic- 
10 tionary) against some known information about the de- 
sired password. The known information may be publicly 
available or may have been obtained by the adversary 
through one of the above-described techniques. Dic- 
tionary attacks are often effective because users often 
*5 choose easily remembered, and easily guessed, pass- 
words. 

[0007] There are various known techniques for net- 
work authentication. These known techniques will be di- 
vided into two classifications. The first classification in- 

20 dudes those techniques that require persistent stored 
data on the client system. The second classification in- 
cludes those techniques which do not require persistent 
stored data on the client system. 
[0008] With respect to the first classification, persist- 

25 ent stored data may include either secret data (e.g. , se- 
cret keys shared with the authenticating server) which 
must never be revealed, or non-secret but sensitive data 
(e.g., the authenticating server's public key) which must 
be tamper-proof. With either type of persistent data, ex- 

30 tra security requirements are necessary to secure the 
data from attack from an adversary. Further, when using 
an authentication protocol which relies on both pass- 
words and persistent stored data, a compromise of ei- 
ther may lead to a vulnerability of the other. For example, 

35 compromising a secret key may lead to a possible dic- 
tionary attack on the password. Another problem with 
this first class of protocols is that persistent stored data 
requires generation and distribution of keys, which can 
be cumbersome, and generally provides a less flexible 

40 system. 

[0009] The second classification is called password- 
only authentication protocols because there is no re- 
quirement of persistent stored data at the client The cli- 
ent only needs to be able to provide a legitimate pass- 
es word. The notion of providing strong security and au- 
thentication using potentially weak passwords seems to 
be contradictory. However, there exist several pass- 
word-only user authentication and key exchange proto- 
cols that are designed to be secure. A description of 
so these protocols may be found in D. Jablon, Strong Pass- 
word-Only Authenticated Key Exchange, ACM Compu- 
ter Communication Review, ACM SIGCOMM, 26(5): 
5-20,1996, the disclosure of which is incorporated by 
reference herein. Some of the more notable of the pass- 
S5 word-only protocols include Encrypted Key Exchange 
(EKE) described in S.M. Bellovin and M. Merritt, En- 
crypted Key Exchange: Password-Based Protocols Se- 
cure Against Dictionary Attacks, Proceedings of the 
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IEEE Symposium on Research in Security and Privacy, 
pp. 72-84, 1992; Augmented-EKE (A-EKE), S.M. Bello- 
vin and M. Merritt, Augmented Encrypted Key Ex- 
change: A Password-Based Protocol Secure Against 
Dictionary A ttacks and Password File Compromise, Pro- 
ceedings of the First Annual Conference on Computer 
and Communications Security, 1993, pages 244-250; 
Modified EKE (M-EKE), M. Steiner, G. Tsudik, and M. 
Waidner, Refinement and Extension of Encrypted Key 
Exchange, ACM Operating System Review, 29:22-30, 
1995; Simple Password EKE (SPEKE) and Diffie-Hell- 
man EKE (DH-EKE), both described in D. Jablon, 
Strong Password-Only Authenticated Key Exchange, 
ACM Computer Communication Review, ACM SIG- 
COMM, 26(5):5-20,1996; Secure Remote Password 
Protocol (SRP), T. Wu, The Secure Remote Password 
Protocol, Proceedings of the 1 998 Internet Society Net- 
work and Distributed System Security Symposium, pag- 
es 97-111, 1998; Open Key Exchange (OKE), Stefan 
Lucks, Open Key Exchange: How to Defeat Dictionary 
Attacks Without Encrypting Public Keys, Security Proto- 
col Workshop, Ecole Normale Sup'erieure, April 7-9, 
1997; Authenticated Key Exchange (AKE), M. Bellare, 
D. Pointcheval,and P. Rogaway, Authenticated Key Ex- 
change Secure Against Dictionary Attacks, Advances in 
Cryptology, pp. 139-155, Eurocrypt 2000; and EP-A- 
1069726. 

[0010] The problem with most of the known pass- 
word-only authentication protocols is that they have not 
been proven secure. In fact, the EKE protocol may be 
susceptible to a certain number of theoretic attacks as 
described in S. Patel, Number Theoretic Attacks on Se- 
cure Password Schemes, Proceedings of the IEEE 
Symposium on Research in Security and Privacy, pages 
236-247, 1997, the disclosure of which is incorporated 
by reference herein. While the AKE protocol has been 
proven secure, it requires strong assumptions to prove 
security. Further, while the SNAP I protocol has also 
been proven secure, the protocol is based on the RSA 
algorithm rather than Diffie-Hellman. 
[001 1 ] EP-A-1 1 34929 discloses a secure password- 
only mutual network authentication and key exchange 
protocol which is provably secure and uses a Diffie-Hell- 
man type shared secret, but modified such that the two 
parties may authenticate each other using a shared 
password. 

Summary of the Invention 

[001 2] The present invention provides a secure pass- 
word-only mutual network authentication protocol which 
is provably secure. In accordance with the inventive pro- 
tocol, two parties generate a shared secret using a Dif- 
fie-Hellman type key exchange. As is known, in accord- 
ance with a Diffie-Hellman type key exchange, there is 
a group generator g for a particular group, an index x 
known to one party, an index y known to the other party, 
and the shared secret g**. One party generates p* the 


other party generates gy, and the parties exchange 
these values so that each party may now generate the 
shared secret g**. While Diffie-Hellman defines a key 
exchange protocol, the protocol has no authentication 
s aspects. 

[0013] Thus, in accordance with the present inven- 
tion, we provide a protocol which uses a Diffie-Hellman 
type shared secret, but modified such that the two par- 
ties may authenticate each other using a shared pass- 

10 word. Further, we have proven that this protocol is se- 
cure. In accordance with the invention, a party gener- 
ates the Diffie-Hellman value g* and combines it with a 
function of at least the password using a group opera- 
tion, wherein any portion of a result associated with the 

is function that is outside the group is randomized. The re- 
sulting value is transmitted to the other party. The group 
operation is defined for the particular group being used, 
and will be described in further detail below. For present 
purposes, it is sufficient to recognize that every group 

20 has a group operation and a corresponding inverse 
group operation. 

[001 4] Upon receipt of the value, the other party per- 
forms the inverse group operation on the received value 
and the function of at least the password, and removes 

25 the randomization of any portion of the result associated 
with the function that is outside the group, to extract cf 
such that the other party may then generate the shared 
secret g** using its knowledge of y. 
[001 5] The use of the group operation and the inverse 

30 group operation in conjunction with a Diffie-Hellman 
type key exchange protocol as described herein pro- 
vides benefits over password-only mutual network au- 
thentication protocols. The randomization of any portion 
of the result associated with the function that is outside 

35 the group reduces the computational intensity associat- 
ed with the operations performed by the one party. Ad- 
vantageously, the present invention provides a protocol 
which can be proven to be secure against attacks by 
adversaries which have access to the communication 

40 channel. 

[0016] As described above, the Diffie-Hellman value 
<j* is combined with a function of at least the password. 
The term "at least" is used because, in various embod- 
iments, g* may be combined with a function of the pass- 
es word alone, or a function of the password along with 
identifiers of the parties to the protocol in order to ensure 
that the password is unique for any particular pair of par- 
ties. 

[0017] In accordance with one embodiment of the in- 
& vention, the parties may authenticate each other by 
computing a function of at least certain parameters, 
transmitting the computed value to the other party, and 
then each party checking the received value against its 
own computed value. The parameters used for the com- 
55 putation may be at least one of a party identifier, the Dif- 
fie-Hellman value (g* or p*), the shared secret, and the 
shared password. By computing a function of at least 
one of these values, the parties may authenticate that 
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the other party is in possession of the shared password. 
[0018] These and other objects, features and advan- 
tages of the present invention will become apparent 
from the following detailed description of illustrative em- 
bodiments thereof, which is to be read in connection with 
the accompanying drawings. 

Brief Description of the Drawings 

[0019] 

FIG. 1 illustrates the Diffie-Hellman key exchange 
protocol; 

FIG. 2 illustrates a mutual authentication and key 
exchange protocol in which both parties possess a 
shared password; 

FIG. 3 illustrates an improved efficiency mutual au- 
thentication and key exchange protocol in accord- 
ance with an embodiment of the present invention 
in which both parties possess a shared password; 
and 

FIG. 4 illustrates a generalized hardware architec- 
ture of a data network and computer systems suit- 
able for implementing one or more of the password- 
authenticated key exchange methodologies ac- 
cording to the present invention. 

Detailed Description of Preferred Embodiments 

[0020] Cryptography is a well-known technique for 
providing secure communication between two parties. 
Prior to describing various embodiments of the present 
invention, some background and basic terminology will 
be provided. 

[0021] Informally, a function f from a set S to a set T 
is a one-way function if f(x) is easy to compute for all x 
in S but for most y in T, it is computationally infeasible 
to find any x in S where f{x) = y. One example of a one- 
way function is modular exponentiation. Let p be a large 
prime and g a generator of the multiplicative group mod 
p (that is, the numbers in the range 1 p-1). Then f(x) 
= g* mod p is generally assumed to be a one-way func- 
tion. The inverse function, called the discrete log func- 
tion, is difficult to compute. There are also other groups 
in which the discrete log function is difficult to compute, 
such as certain elliptic curve groups. 
[0022] Let and / denote security parameters, where 
k is the main security parameter and can be thought of 
as a general security parameter for hash functions and 
secret keys (e.g., 160 bits), and /> Ar can be thought of 
as a security parameter for discrete-log-based public 
keys (e.g., 1024 or 2048 bits). Let {0,1 }* denote the set 
of finite binary strings and {0,1 V denote the set of binary 
strings of length n. A real-valued function z{n) is negli- 
gible if for every c> 0, there exists n c > 0 such that z(n) 
< Mrf for all n > Let q of size at least k and p of size 
/ be primes such that p - rq + 1 for some value r co- 
prime to q. Let g be a generator of a subgroup of Z* p of 


size q. Call this subgroup G pq . 
[0023] A key exchange protocol called Diffie-Hellman 
Key Exchange and described in W. Diffie and M. Hell- 
man, New Directions in Cryptography, IEEE Transac- 

5 tions on Information Theory, vol. 22, no. 6, 644-654, 
1976, the disclosure of which is incorporated by refer- 
ence herein, is based on the modular exponentiation 
function. Specifically, two parties A and B agree on a 
secret key in accordance with the protocol described in 

to conjunction with FIG. 1 . In step 102, A chooses a ran- 
dom xfrom the group Z q (i.e., x S R Z^ where Z q = {0, 

1 oyl} (or simply the integers mod q). In step 104, A 

computes X = g* mod p. In step 106, A transmits Xto 
B. In step 1 08, B chooses a random y f rom Z q (i.e.. y G fl 

15 Z^. In step 1 1 0, B computes Y= qy mod p and transmits 
YXo A in step 112. At this point, a shared secret g*y (i. 
e., a secret key) can be computed by both A and B. Note 
that herein below we may ignore the mod p notation for 
notational simplicity if it is clear that we are working in 

20 mod p. Since X = g* was transmitted from A to B in step 
1 06, B can calculate the shared secret g*y by computing 
Xy in step 116. Similarly, since Y = gy was transmitted 
from B to A in step 1 1 2, A can caicu late the shared secret 
g*y by computing V* in step 114. The shared secret S 

25 can now be used by A and B as a session key for secure 
communication. 

[0024] Diffie-Hellman key exchange can also be per- 
formed over other groups in which the discrete log func- 
tion is difficult to compute, such as certain elliptic curve 

30 groups. Groups are well-known in the art, as described 
in I.N. Herstein, Topics in Algebra, 2nd edition, John Wi- 
ley & Sons, New York, 1975, the disclosure of which is 
incorporated by reference herein, as follows. A nonemp- 
ty set of elements G is said to form a group if in G there 

35 is defined a binary operation, called the product and de- 
noted by such that: 

1 a, b G G implies that a-beG (closed). 

2 a, b, c, G G implies that a > {b • c) = {a • b) • c 
40 (associative law). 

3 There exists an element e G G such that a . e = 
e • a = a for all a G G (the existence of an identity 
element in G). 

4 For every a G G there exists an element a~ 1 G G 
45 such that a • a- 1 = ar 1 • a = e (the existence of in- 
verses in G). 

[0025] Thus, more generally, Diffie-Hellman key ex- 
change operates in a specific group where the secret 

so keys xand y are indices to elements of the group. Thus, 
consider a group G with a group generator g G G and 
G = {9, 9 • 9, 9 • g • g, g • g • g • g, ~ } where . is the 
group operation . As examples, if the group operation for 
G is multiplication, then G = {g 1 , g* t p^, g+, -»}. If the 

55 group operation • for G is addition, then G = {1 g, 2g t 3g r 
4g, *» }. Since the present invention may be implemented 
using different groups, as used herein below, the nota- 
tion p* means that the group operation is applied x times 
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on the group generator g. Further, for every group, there 
is also an inverse group operation represented herein 
as - As used herein below, the inverse group operation 
is defined as follows. The inverse group operation on x 
and y, i.e., -, is defined as x-y 1 . 
[0026] Fife. 2 illustrates a mutual authentication and 
key exchange protocol in accordance with an explicit au- 
thentication approach in which both parties possess a 
shared password. The communication protocol in FIG. 
2 is disclosed in the above-referenced EP-A-1 134929. 
[0027] In general, the communication protocol uses a 
Diffie-Hellman type shared secret, but modified such 
that the two parties may authenticate each other using 
a shared password. Further, it has been proven that this 
protocol is secure. 

[0028] In accordance with FIG. 2, steps shown on the 
left side of the figure are performed by a first party A, 
and steps shown on the right side of the figure are per- 
formed by a second party B. Typically, A is a client ma- 
chine (computer system) and B is a server machine 
(computer system). However, this is not required, and 
A and B are referred to as client and server, respectively, 
only as an example to show the typical case. Thus, it is 
to be understood that the approach shown in FIG. 2 is 
not limited to the case where A and B are cl lent and serv- 
er, but instead is applicable to any two parties A and B. 
Arrows represent communication between the parties. 
In accordance with the protocol, the server authenti- 
cates Itself to the client and the client authenticates itself 
to the server. After both sides have authenticated, each 
generates a secret session key which may be used for 
subsequent secure communication. 
[0029] Prior to initiation of the protocol, it is assumed 
thatthe client and the server are in possession of a pass- 
word n which the client uses to authenticate with the 
server. 

[0030] It is noted that the following protocol authenti- 
cates both the server and the client. Thus, neither the 
server nor the client are assumed to be authentic, and 
thus either the server or the client may be an adversary. 
The client may be an adversary attempting to authenti- 
cate itself and gain access to the server. The server may 
be an adversary attempting to spoof another authentic 
server in an attempt to gain sensitive information from 
an unsuspecting client. 

[0031 ] Returning now to FIG. 2, in step 202, the client 
chooses a random value for the index xfrom Then, 
in step 204, the client computes a parameter m as m = 
p* • (M| (A, B, it))' mod p, where A is a unique identifier 
of the client, B is a unique identifier of the server, n is 
the client's password for this particular server, is a 
random hash function, and represents the group oper- 
ation. W, {A, B, it) is raised to the r power in order to 
ensure that the result is within Informally, a func- 
tion Hfrom a set S to a set Twill be called a random 
hash function if the output of H looks random or at least 
is unpredictable until the function is computed with an 
input x in S. Since H A must output something that looks 


random in Z*^ it should output Ipl + sec bits (where Ipl 
is the number of bits of p and sec is the security param- 
eter. The security parameter may be, for example, 1 60. 
Known functions that generally behave this way are 
5 SHA-1 , described in FIPS 1 80-1 , Secure Hash Stand- 
ard, Federal Information Processing Standards Publica- 
tion 1 80-1 , 1 995; and RIPEMD-1 60, described in H. Do- 
bbertin, A. Bosselaers, B. Preneel, RIPEMD-1 60: a 
strengthened version ofRtPEMD, In Fast Software En- 
io cryption, 3rd Intl. Workshop, 71-82, 1996, the disclo- 
sures of which are incorporated by reference herein. 
[0032] The tuple (A, B r n) is used, rather than only the 
password, in order to ensure that It is unique for each 
client-server pair. The password alone is all that is re- 
's quired for heuristic security, but, as discussed in further 
detail below, the client and server names are used to 
ensure a formal proof of security. Thus, in accordance 
with the protocol in FIG. 2, a function of at least the pass- 
word is combined with the Diffie-Hellman value by 
20 performing the group operation on the function of at 
least the password and the Diffie-Hellman value o* This 
is an important step of the protocol as it ensures that the 
Diffie-Hellman value g* may only be extracted from the 
parameter m by someone who has knowledge of the 
25 password. This extraction of the Diffie Hellman value g* 
will be described in further detail below in conjunction 
with step 214. In step 206, the client transmits the pa- 
rameter m to the server. 

[0033] Upon receipt of the parameter m, the server 
30 tests the parameter value in step 208 to ensure thatthe 
value is not 0 mod p. If the value is 0 mod p, the server 
terminates the protocol because 0 is not in Z*p. Other- 
wise, in step 210, the server chooses a random value 
for the index /from Z v In step 212, the server assigns 
35 a parameter u, to the computed Diffie-Hellman value or. 
Next, in step 214, the server computes the Diffie-Hell- 
man shared secret g*y (referred to as o in this protocol) 
using the received parameter m as follows: 


40 



iH A (A,B,n))'j 


mod p. We will now describe this step in further detail 
45 (leaving out the mod p notation for notational simplicity). 
First, it should be recalled that, as described above, for 
every group operation, there is an inverse group oper- 
ation such that the inverse group operation on x and y, 
i.e. -, is defined as x • y 1 . Thus, one skilled in the art 
so wouTd recognize that the calculation of 

m 

((*,(*, B, n)V 

55 

in step 214 is performing the inverse group operation on 
m and the function of at least the password. Substituting 
the value of m from step 204, we have 
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({H i (A t B t n)) r 

Thus, It the server has possession of the correct pass- 
word n, then the server can extract the Diffie Heltman 
value p* from the value of the received parameter m. 
Thus, the computation in step 214 results in the server 
generating the Drffie-Hellman shared secret g**. 
[0034] Next, in step 21 6, the server computes k = 
(A B, m, u., a, n), where Hfe a is another random hash 
function which must output sec bits, where sec is the 
security parameter. The parameter * will be used by the 
client A, as described below, to authenticate that the 
server is in possession of the correct password. In step 
21 8, the server transmits parameters u. and k to the cli- 
ent. 

[0035] Upon receipt of parameters u. and k, the client 
computes o = u* mod p in step 220. Since u. = 9*, u* = 
g*y, which is the DifTie-Hellman shared secret In step 
222, the client computes (A, B, m, u., o, n) using its 
own knowledge of n and tests whether the result is equal 
to the parameter k received from the server in step 21 8. 
If they are the same, then the client has authenticated 
the server. If they are not the same, then the client ter- 
minates the protocol as the server has not authenticated 
itself. In step 224, the client computes k'^H^ (A, B, m, 
u., a, n) which will be used by the server to authenticate 
the client as described below. In step 226, the client gen- 
erates session key Kas K= H$(A,B,n\ u., o, n). In step 
228, the client transmits k to the server. Again, and 
H$ are random hash functions which must output sec 
bits, where sec is the security parameter. 
[0036] In step 230, the server computes Hg, (A, B, m, 
\l, a, 7i) using Its own knowledge of n and tests whether 
the result is equal to the parameter k 1 received from the 
client In step 228. If they are the same, then the server 
has authenticated the client. If they are not the same, 
then the server terminates the protocol as the client has 
not authenticated itself. In step 232, the server gener- 
ates session key AC as K= H$ (A, B, m, n, a, n). 
[0037] At this point, both the client and server have 
authenticated with each other, and both the client and 
the server have generated the same secure session key 
K t which may be used for subsequent secure commu- 
nication between the client and the server. 
[0038] Thus, while the communication protocol of 
FIG. 2 provides the advantages of key exchange with 
password-based authentication, the generation of the 
parameter m as o* • (Hj (A B, n)) r mod p can be com- 
putationally intense. This can be problematic when the 
client device does not possess the computational re- 
sources to adequately perform this portion of the proto- 
col. This may be the case when the client A is a smaller, 
slower device such as an older generation personal 
computer, a smartcard, or a handheld personal digital 
assistant (PDA), to name a few examples. Also, while 
B may be a server and is assumed to be more compu- 


tationally equipped than the client, the protocol may be 
performed between two client-type devices and thus 
computational efficiency is important on both sides of 
the protocol. A solution which is able to reduce the client- 
s side computation by at least a factor of two is provided 
in accordance with the present invention and illustrated 
in the context of FIG. 3. 

[0039] Referring nowto FIG. 3, an improved efficiency 
mutual authentication and key exchange protocol is pro- 

io vided in accordance with an embodiment of the present 
invention in which both parties possess a shared pass- 
word. Hie communication protocol is a secure pass- 
word-authenticated key exchange protocol and as- 
sumes the hardness of the Decision Drffie-Hetlman 

is problem (DDH) in G A<r Let DH(X f V) denote the Drffie- 
Hellman value g*y of X = 9* and Y = <y, as described 
above. One formulation is that given g t X, Y, Zin G Aq , 
where X=g* and Y= §f are chosen randomly, and Zis 
either DH{X, V) or random, each with half probability, 

20 determine if Z= DMJC, V). Breaking DDH implies con- 
structing a polynomial-time adversary that distinguishes 
Z= DH(X f Y) from a random Zwith non-negligible ad- 
vantage over a random guess. 
[0040] Further, we define hash functions H^, H^, Hj: 

25 {0, 1}* -» {0, 1}* and {0.1}* {0,1}^, where ti 2t /+ 
it We also assume that H p H^, H^, and Wj are inde- 
pendent random functions, as used above in the ap- 
proach of FIG. 2. Note that while H, is described as re- 
turning a bit string, we operate on Its output as a number 

30 modulo p. 

[0041] In accordance with the communication proto- 
col of FIG. 2, note that the client performs two I pi -bit 
exponentiations (steps 204 and 220), and one Iri -bit ex- 
ponentiation (step 204). As will be explained below in 

35 the context of FIG. 3, in accordance with a communica- 
tion protocol of the present invention, the client only 
needs to perform three \cf -bit exponentiations, which 
generally require much less computation as compared 
with the protocol of FIG. 2. The invention is able to pro- 

40 vide such an advantage in the following man ner. Instead 
of forcing the result of the hash function used to gener- 
ate parameter m to be in the group G p q) we allow the 
result of the hash function to be any element in Z*^ and 
randomize that part of the hash function result outside 

45 of G M This makes the m value indistinguishable from 
a random value in Z* p (instead of a random value in 
G Aq ), but still allows one to extract the hash value and 
the extra randomization. 

[0042] In this case, we have p = rq + 1 in which gcd 
so (r, q) = 1 (where gcd stands for greatest common divi- 
sor), in order to extract the extra randomization. Of 
course, for randomly chosen q and p (for instance, using 
the NIST approved algorithm described in U.S. Depart- 
ment of Commerce/NIST, Springfield, VA, FIPS1B6, 
ss "Digital Signature Standard," Federal Information 
Processing Standards Publication 1B6, 1994, the dis- 
closure of which is incorporated by reference herein), 
this relation may be satisfied with high probability. 
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[0043] As with FIG. 2, steps shown on the left side of 
FIG. 3 are performed by a first party A, and steps shown 
on the right side of FIG. 3 are performed by a second 
party B. Again, A is referred to as a client machine (com- 
puter system) and B as a server machine (computer sys- 5 
tem) only as an example to show a typical case. Thus, 
it is to be understood that the protocol shown in FIG. 3 
is applicable to any two entities or parties A and B. 
Again, arrows represent communication between the 
parties. In accordance with the protocol of FIG. 3, the io 
server authenticates itself to the client and the client au- 
thenticates itself to the server. Thus, neither the server 
nor the client are assumed to be authentic, and thus ei- 
ther the server or the client may be an adversary, as 
explained above. After both sides have authenticated, « 
each generates a secret session key which may be used 
for subsequent secure communication. 
[0044] As with the FIG. 2 protocol , prior to initiation of 
the FIG. 3 protocol of the invention, it is assumed that 
the client and the server are in possession of a password 20 
% which the client uses to authenticate with the server. 
[0045] Returning now to FIG. 3, in step 302, the client 
chooses a random value for the index xfrom 2^ (i.e., x 
S R Z^}. In step 304, the client chooses a random value 
h from the group Z* p (i.e., h G fl Zy. Then, in step 306, 25 
the client computes a parameter mas m- • bfl • 
(A, B, n), where A is a unique identifier of the client, B 
is a unique identifier of the server, n is the client's pass- 
word for this particular server, W, is a random hash func- 
tion, • represents the group operation, and ft* is a rand- so 
omization operation. Recall that in the protocol of FIG. 
2, W, {A, B, n) is raised to the r power in order to ensure 
that the result is within G Pttr However, in accordance 
with the present invention, instead of forcing the result 
of the hash function used to generate parameter m to 35 
be in the group the protocol of FIG. 3 allows the 
result of the hash function to be any element in Z , and 
randomizes that part of the hash function result ofitside 
of Gp^ This is accomplished via the randomization op- 
eration M. This makes the m value indistinguishable *o 
from a random value in Z , instead of a random value 
in G A4 , but still allows the'server B to extract the hash 
value and the extra randomization. Advantageously, by 
raising the random parameter h to the exponent q, eve- 
rything in the result of the hash function outside of the 
subgroup G^ q is randomized. 
[0046] As explained above, a function Hfrom a set S 
to a set Twill be called a random hash function if the 
output of H looks random or at least is unpredictable until 
the function is computed with an input xin S. Thus, since so 
^ must output something that looks random in Z* ( it 
should output Ipl + sec bits (where Ipl is the numbed of 
bits of p and sec is the security parameter. The security 
parameter may be, for example, 160. Again, the SHA-1 
or the Rl PEMD-1 60 are known functions that generally 55 
behave this way. 

[0047] As in the protocol of FIG. 2, the tuple (A, B f n) 
is used, rather than only the password, in order to en- 


sure that it is unique for each client-server pair. The 
password alone is all that is required for heuristic secu- 
rity, but the client and server names may be used to en- 
sure a formal proof of security. Thus, in accordance with 
the protocol in FIG. 3, a function of at least the password 
is combined with the Diff ie-Hellman value p*by perform- 
ing the group operation on the function of at least the 
password and the Diff ie-Hellman value g*. Again, this is 
an important step of the protocol as it ensures that the 
Diffie-Hellman value 9* may only be extracted from the 
parameter m by someone who has knowledge of the 
password. In step 308, the client transmits the parame- 
ter m to the server. 

[0048] Upon receipt of the parameter m, the server- 
tests the parameter value in step 31 0 to ensure that the 
value is not 0 mod p. If the value is 0 mod p, the server 
terminates the protocol because 0 is not in z\ Other- 
wise, in step 312, the server chooses a random value 
for the index y from Zg. In step 314, the server assigns 
a parameter u. to the computed Diffie-Hellman value p/. 
Next, in step 316, the server computes the Diffie-Hell- 
man shared secret g*y (referred to as o in this protocol) 
using the received parameter m as follows: 

'■fhMf-"- 

We will now describe this step in further detail. First, it 
should be recalled that, as described above, for every 
group operation, there is an inverse group operation 
such that the inverse group operation on xand y, i.e. -, 
is defined as x y 1 . Thus, one skilled in the art woufd 
recognize that the calculation of 

'-{(jmrnrr'"" 

in step 31 6 is performing the inverse group operation on 
m and the function of at least the password, as well as 
extracting the randomization associated with the client 
random operation M. Substituting the value of m from 
step 306, we get p* Thus, if the server has possession 
of the correct password n, then the server can extract 
the Diffie Hellman value p*f rom the value of the received 
parameter m. Thus, the computation in step 31 6 results 
in the server generating the Diffie-Hellman shared se- 
cret 

[0049] Next, in step 31 8, the server computes /r = ffe a 
{A, B t m, n, a, ji), where flfe fl is another random hash 
function which must output sec bits, where sec is the 
security parameter. The parameter Arwill be used by the 
client A, as described below, to authenticate that the 
server is in possession of the correct password. In step 
320, the server transmits parameters u. and kto the cli- 
ent 

[0050] Upon receipt of parameters u. and k, the client 
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computes o = \i x mod p in step 322. Since u, = p*, = 
(fy, which is the Diffie-Hellman shared secret In step 
324, the client computes {A, B, m, u,, o, 7i) using its 
own knowledge of ic and tests whether the result is equal 
to the parameter k received from the server in step 320. 
If they are the same, then the client has authenticated 
the server. If they are not the same, then the client ter- 
minates the protocol as the server has not authenticated 
Itself. In step 326, the client computes K = H 2b (A, B, m, 
u., o, n) which will be used by the server to authenticate 
the client as described below. In step 328, the client gen- 
erates session key Kas K= H$ (A, B, m, u>, o, rc). In step 
330, the client transmits /r'to the server. Again, and 
H$ are random hash functions which must output sec 
bits, where sec is the security parameter. 
[0051] In step 332, the server computes {A, B, m, 
p., o, n) using its own knowledge of n and tests whether 
the result is equal to the parameter W received from the 
client in step 330. If they are the same, then the server 
has authenticated the client. If they are not the same, 
then the server terminates the protocol as the client has 
not authenticated itself. In step 334, the server gener- 
ates session key Kas K= H$ (A, B, m, u., o, n). 
[0052] At this point, both the client and server have 
authenticated with each other, and both the client and 
the server have generated the same secure session key 
K t which may be used for subsequent secure commu- 
nication between the client and the server. 
[0053] As mentioned above, the communication pro- 
tocol of the invention, as illustrated in the context of FIG. 
3, reduces the client-side computation by at least a fac- 
tor of two, as compared to the protocol of RG.2. This is 
evident from the following example. Assume p is a 1 024 
bit prime, and q is a 160 bit prime. Then, r is 864 bits. 
Every exponentiation in Z takes time proportional to the 
number of bits of the exponent. Then, in the protocol of 
FIG. 2, where two q-b\t exponentiations and one r-brt 
exponentiation are performed, the time is proportional 
to 2* 160 + 864 = 1184, while in the protocol of the in- 
vention (as illustrated in FIG. 3) where three p^bit expo- 
nentiations are performed, the time is proportional to 3 
* 160 = 480. Advantageously, this value (480) is less 
than half the value associated with the FIG. 2 protocol 
(1184). 

[0054] FIG. 4 illustrates a generalized hardware ar- 
chitecture of a data network and computer systems suit- 
ablefor implementing a password-authenticated key ex- 
change methodology between two entities A and B ac- 
cording to the present invention. As shown, entity A 
comprises a computer system 402, while entity B com- 
prises a computer system 404. The two computer sys- 
tems 402 and 404 are coupled via a data network 406. 
The data network may be any data network across 
which A and B desire to communicate, e.g, the Internet 
However, the invention is not limited to a particular type 
of network. Typically, and as labeled in FIG. 4, A is a 
client machine and B is a server machine. However, this 
is not required, and A and B are referred to as client and 


server, respectively, only as an example to show the typ- 
ical case. Thus, it is to be understood that the commu- 
nication protocol of the present invention is not limited 
to the case where A and B are client and server, but 
5 instead is applicable to any computing devices compris- 
ing A and B. 

[0055] As would be readily apparent to one of ordinary 
skill in the art, the server and client may be implemented 
as programmed computers operating under control of 

io computer program code. The computer program code 
would be stored in a computer readable medium (e.g., 
a memory) and the code would be executed by a proc- 
essor of the computer Given this disclosure of the in- 
vention, one skilled in the art could readily produce an- 
te propriate computer program code in order to implement 
the protocols described herein. 
[0056] Nonetheless, FIG. 4 generally illustrates an ex- 
emplary architecture for each computer system commu- 
nicating over the network. As shown, the client device 

20 comprises I/O devices 408-A, processor 410-A, and 
memory 41 2-A. The server system comprises I/O devic- 
es 408-B, processor 410-B, and memory 412-B. It 
should be understood that the term "processor" as used 
herein is intended to include one or more processing de- 

25 vices, including a central processing unit (CPU) or other 
processing circuitry. Also, the term "memory" as used 
herein is intended to include memory associated with a 
processor or CPU, such as RAM, ROM, a fixed memory 
device (e.g., hard drive), or a removable memory device 

30 (e.g., diskette or CD ROM). In addition, the term "I/O de- 
vices" as used herein is intended to include one or more 
input devices (e.g., keyboard, mouse) for inputting data 
to the processing unit, as well as one or more output 
devices (e.g., CRT display) for providing results associ- 

35 ated with the processing unit. Accordingly, software in- 
structions or code for performing the methodologies of 
the invention, described herein, may be stored in one or 
more of the associated memory devices, e.g., ROM, 
fixed or removable memory, and, when ready to be uti- 

40 lized, loaded into RAM and executed by the CPU. 
[0057] Although illustrative embodiments of the 
present invention have been descrfoed herein with ref- 
erence to the accompanying drawings, it is to be under- 
stood that the invention is not limited to those precise 

45 embodiments, and that various other changes and mod- 
ifications may be affected therein by one skilled in the 
art without departing from the scope or spirit of the In- 
vention. For example, while the teachings of the inven- 
tion have been illustrated in the context of a communi- 

so cation protocol which provides computational efficien- 
cies over the communication protocol described above 
in FIG. 2, it is to be understood that the invention may 
be applied in the context of other communication proto- 
cols. For example, the randomization operation of the 

55 invention may be employed in accordance with other 
protocol embodiments described in the above-refer- 
enced EP-A-1 11 34929. 

[0058] For example, the invention may be employed 


8 


15 


EP 1 248 408 A2 


16 


in accordance with the implicit authentication approach 
of the above-reference application, as well as with the 
password verifier approach described therein. Further- 
more, while certain parameters are used in evaluating 
the hash functions of the communication protocol of the 5 
invention, it is to be understood that not all parameters 
are required for heuristic security. That is, additional pa- 
rameters are used to allow the protocol to be formally 
proven secure. For example, in the hash functions used 
in steps 31 8, 324, 326, 328, 332, and 334, only the pa- 10 
rameter a in the function may be needed to make the 
protocol heuristically secure. 


Claims is 

1 . A method for communication via a data network, be- 
tween two parties that share a password, using a 
Diffie-Hellman type key exchange on a particular 
group to generate a shared secret p^, where p is 20 
the group generator known to both parties and x is 

an index known to one party and/is an index known 
to the other party, the group having a group opera- 
tion and an inverse group operation, the method 
comprising the steps of: 25 

one party generating a parameter m by per- 
forming the group operation on g* and a func- 
tion of at least the password, wherein any por- 
tion of a result associated with the function that so 
is outside the group is randomized, and trans- 
mitting m to the other party, whereby the other 
party may perform the inverse group operation 
on m and the function of at least the password, 
and remove the randomization of any portion of 35 
the result associated with the function that is 
outside the group, to extract p* and calculate 
the shared secret p^. 

2. The method of claim 1 , wherein the particular group, * *o 
denoted as G M is a subgroup of a group Z where 

p and q are prime numbers such that p equals rq + 
I for a value r co-prime to q, and wherein the step 
of randomizing any portion of a result associated 
with the function that is outside the group G^ q is ^ 
performed by computing a^ parameter h, randomly 
selected from the group Z , raising the parameter 
h to the exponent q and multiplying hfl by the result 
associated with the function. 

so 

3. The method of claim 1 , wherein the one party is a 
client and the other party is a server. 

4. The method of claim 1 , further comprising the step 

of: 55 

the one party receiving p? from the other party 
and generating the shared secret gW. 


5. The method of claim 4, further comprising the step 
of: 

the one party authenticating the other party by 
comparing a received value against a function 
of at least one of an identifier of the one party, 
an identifier of the other party, m, p/, the shared 
secret, and the password. 

6. The method of claim 4, further comprising the step 
of: 

the one party transmitting a function of at least 
one of an identifier of the one party, an identifier 
of the other party, m, pK, the shared secret, and 
the password, to the other party whereby the 
other party may authenticate the one party. 

7. The method of claim 4 further comprising the step 
of. 

the one party generating a session key as a 
function of at least one of an identifier of the one 
party, an identifier of the other party, m, p?, the 
shared secret, and the password. 

8. A method for communication via a data n etworic, be- 
tween two parties that share a password, using a 
Diffie-Hellman type key exchange on a particular 
group to generate a shared secret p*y, where g is 
the group generator known to both parties and x is 
an index known to one party and y is an index known 
to the other party, the group having a group opera- 
tion and an inverse group operation, the method 
comprising the steps of: 

responsive to the one party generating a pa- 
rameter m by performing the group operation 
on p* and a function of at least the password, 
wherein any portion of a result associated with 
the function that is outside the group is rand- 
omized, and transmitting m to the other party, 
the other party performing the inverse group 
operation on m and the function of at least the 
password, removing the randomization of any 
portion of the result associated with the function 
that is outside the group, extracting p* and cal- 
culating the shared secret g*y. 

9. Apparatus for use in accordance with a protocol for 
communication over a data network between two 
parties that share a password, using a Diffie-Hell- 
man type key exchange on a particular group to 
generate a shared secret pv, where p is the group 
generator known to both parties and x is an index 
known to one party and y is an index known to the 
other party, the group having a group operation and 
an inverse group operation, said apparatus being 
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for use by the one party and comprising: 

at least one processor operative to: (/) generate 
a parameter m by performing the group opera- 
tion on g* and a function of at least the pass- 5 
word, wherein any portion of a result associated 
with the function that is outside the group is ran- 
domized; and (ii) transmit m to the other party, 
whereby the other party may perform the in- 
verse group operation on m and the function of io 
at least the password, and remove the randomi- 
zation of any portion of the result associated 
with the function that is outside the group, to 
extract o* and calculate the shared secret p^. 

15 

10. Apparatus for use in accordance with a protocol for 
communication over a data network between two 
parties that share a password, using a Drffle-Hell- 
man type key exchange on a particular group to 
generate a shared secret p^, where g is the group 20 
generator known to both parties and x is an index 
known to one party and y is an index known to the 
other party, the group having a group operation and 
an inverse group operation, said apparatus being 
for use by the other party and comprising: 2s 

at least one processor operative to, in response 
to the one party generating a parameter m by 
performing the group operation on o* and a 
function of at least the password, wherein any 30 
portion of a result associated with the function 
that is outside the group is randomized, and 
transmitting mto the other party: (i) perform the 
inverse group operation on m and the function 
of at least the password; (ii) remove the rand- 35 
omization of any portion of the result associated 
with the function that is outside the group; (Hi) 
extract p*; and (rv) calculate the shared secret 
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